home *** CD-ROM | disk | FTP | other *** search
- Path: engnews1.Eng.Sun.COM!taumet!clamage
- From: "nicolas (n.) chapados" <chapados@bnr.ca>
- Newsgroups: comp.std.c++
- Subject: Re: FW: Inherent C++ problem?
- Date: 21 Jan 1996 15:37:04 GMT
- Organization: Bell Northern Research
- Approved: clamage@eng.sun.com (comp.std.c++)
- Message-ID: <4ds2pp$n5p@bmtlh10.bnr.ca>
- References: <01BAE696.8C249300@dino.int.com>
- NNTP-Posting-Host: taumet.eng.sun.com
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Nntp-Posting-Host: bmtlh567.bnr.ca
- X-Mailer: Mozilla 1.1 (X11; I; HP-UX A.09.05 9000/712)
- X-Url: news:01BAE696.8C249300@dino.int.com
- Content-Length: 771
- Originator: clamage@taumet
-
- Eugene Lazutkin <eugene@int.com> wrote:
- >To me, the step (2) can be eliminated by certain amendment to the semantics
- >of the language while (3) seems to be inherent. I wonder though if
- >something could be done about it within the bounds of the current
- >standard...
-
- See ARM section 12.1c. "The fundamental rule is that the introduction of
- a temporary object and the calls of its constructor/destructor pair may be
- eliminated if the only way the user can detect its elimination or
- introduction is by observing side effects generated by the constructor
- or destructor call."
-
- In your case, all temporaries can be eliminated.
-
- ----
- Nicolas Chapados Member of Scientific Staff
- chapados@bnr.ca Bell-Northern Research Ltd.
-
-
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-
-